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SUMMARY 

OBJECTIVE 

In  rccfiit  years  high  level  languages  for  eontinuous  system  simulation  have  been  de- 
signed to  exeeute  on  general  purpose  digital  eomputers  which  have  traditional  von  Neumann- 
type  architectures.  This  approach  has  produced  varying  results  including  a multiple  layer  of 
system  software  reiiihred  to  implement  and  exeeute  the  simulation  language.  In  most  eases, 
users  have  been  constrained  to  perform  noninteractive  simulations  at  a high  cost.  In  an 
attempt  to  alleviate  some  of  these  problems,  this  study  addressed  the  application  of  direct 
execution  computer  architecture  concepts  using  low-cost,  large-scale-integration  (LSI)  to 
eontinuous  system  simulation.  This  report  summari/.es  work  performed  up  to  October  1 ‘)78. 

RESULTS 

Ba.sie  architecture  schemes  for  direct  execution  systems  were  investigated  and 
applied  to  a demonstration  interactive  simulation  language.  A dual  processor  direct  execu- 
tion system  was  designed  and  built  u.sing  an  LSl-l  1 microcomputer,  a 16  K X 16  dual  port 
memory,  a microprogrammed  AMD  2900  bit-slice  direct  execution  processor,  and  a 16  X 16 
multiplier  chip.  The  system  features  a distinct  separation  of  interpretive/compiler  software 
and  simulation  run  execution  firmware  linked  via  the  dual  port.  The  system  is  demonstrat- 
ed via  several  simulation  examples  including  realtime  control,  optimization,  and  torpedo 
dynamics  problems. 

RECOMMENDATIONS 

The  study  revealed  several  key  points  in  applying  direct  execution  architectures  to 
continuous  system  simulation.  A direct  execution  system,  similar  to  the  one  demonstrated, 
can  be  used  to  replace  analog  computer-type  functions  in  hybrid  simulation  systems,  process 
control  and  instrumentation,  and  simulation  model  development  systems.  Extensions  to  the 
architecture  can  be  made  from  miltiprocessor  simulation  systems.  Scale-free  lloating  point 
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INTRODUCTION 


* 


Traditionally,  high  level  languages  (HLL)  have  been  implemented  on  von  Neumann 
architecture  computers  which  consist  of  a central  processing  unit,  input/output  bus,  user 
interfaces,  and  program/data  memory.  In  particular,  high  level  simulation  languages  for  the 
solution  of  dynamic  continuous  systems  have  been  implemented  on  large  mainframe  and 
minicomputer  systems  in  batch  and  interactive  modes  (1,2,  3).  Simulation  programs 
written  in  high  level  languages  have  been  first  translated  into  compiler  or  assembler-based 
languages,  relocatable  code  produced,  and  linked  with  a simulation  run-time  library  in 
order  to  create  a run  module  executable  by  the  host  processor.  Figure  1 depicts  this  process 
where  the  host  processor  also  executes  the  editor,  translator,  compiler,  assembler,  linking 
loader,  and  input/output  operations.  This  report  summarizes  a different  approach  to  the 
design  and  use  of  high  level  simulation  languages  and  represents  the  application  of  large- 
scale-integration  and  advanced  computer  technology  to  continuous  system  simulation.  The 
results  depict  a digital  system  design  which  can  directly  execute  a high  level  simulation 
language. 


HLL 

CODE 


INTERNAL  RELOCATABLE  ABSOLUTE  INTERNAL 

CODE  CODE  CODE  CODE 


results 


COMPUTER  SYSTEMS  HLLs 

PDP-11  FORTRAN 

IBM  360,  370  ALGOL 

UNIVAC1108  CMS-2 

NOTE;  ONE  PROCESSOR  DOES  IT  ALL 


Figure  I . HLL  in  a traditional  von  Neumann  architecture. 

Several  large-scale-integration  technology  characteristics  contribute  to  the  application 
of  direct  execution  to  simulation.  First,  bipolar  technology  parts  offer  a high  speed  com- 
putational capability.  Microprogrammable  bit-slice  microproces.sor  parts  can  be  used  to 
design  a computer  architecture  optimized  for  continuous  system  simulation.  Second,  large- 
scale-integration  special  purpose  function  units  are  commercially  available  which  can  be 
used  to  compute  highly  repetitive  operations  and  mathematical  functions,  such  as  multiply 
and  sine/cos,  which  fre()uently  arise  in  .simulation.  A typical  example  is  the  16-bit  multiplier 
chip  from  TRW  (4).  In  addition,  support  systems  for  large-scale-integration  devices  are 
I available  which  enable  the  user  to  spend  added  time  on  system  development  rather  than  on 

development  tools. 

, ' Direct  execution  computer  architectures  represent  a departure  from  the  von  Neumann 

inlluenced  relationship  between  computer  and  higli  level  language.  In  a direct  execution  com- 
puter architecture,  the  high  level  language  is  the  machine  language  of  the  system  (5).  The  high 
' level  language  constructs  are  directly  executed  in  hardware  without  the  need  for  separate 

software  parts  such  as  compilers,  assemblers,  and  linking  loaders.  Figure  2 depicts  this  process. 
The  language  constructs  may  be  executed  on  a symbol-by-symbol  (or  token-by-token), 
statement-by-statement,  or  procedural  section  basis.  The  basic  functional  elements  which  are 
used  to  perform  direct  execution  of  a high  level  language  include  (6): 
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• input/output  processor 

• text  editor 

• lexical  scan  and  syntax  processor 

• control  processor 

• arithmetic  processor 

• data  structure  processor 

• processor  intercommunication  buses  and  memories 

• special  function  computation  units 

Large-scale-integration  makes  implementation  of  these  functional  parts  feasible.  For  example, 
interpreters  of  the  1960’s  and  early  1970’s  required  large  memories  and  were  slow  in  execution. 
However,  today’s  advanced  memory  technology  features  64K  bit  chips  and  sub-microsecond 
cycle  times  (7). 
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Figure  2.  HLL  in  a direct  execution  architecture  computer  system. 


The  content  of  this  report  expands  on  the  points  described  above  including  a brief 
overview  of  previous  direct  execution  computer  architecture  work.  The  reasons  for  the 
application  of  direct  execution  computer  architecture  concepts  to  simulation  are  discussed. 

A specific  high  level  simulation  language  is  presented  and  used  as  a basis  for  the  detailed  LSI 
design  of  a dual  processor  direct  execution  system.  Finally,  potential  application  areas  for 
direct  execution  computer  architecture  are  explored  and  follow-on  work  proposed. 

BRIEF  HISTORY  OF  DIRECT  EXECUTION  COMPUTER  ARCHITECTURE 

Useful  in  this  area  as  background  material,  the  text  edited  by  Chu  (8)  contains  a com- 
prehensive survey  of  the  field.  A reference  list  compiled  by  Carlson  (9)  summarizes  the 
history  of  direct  execution  computer  architectures  and  their  relationship  to  high  level  pro- 
gramming languages.  A few  samples  of  work  performed  are  brietly  reviewed  here. 

Research  in  the  relationship  of  high  level  programming  languages  to  computer 
architectures  started  as  early  as  the  I950’s,  however,  the  first  computer  system  design  with 
the  concept  of  direct  execution  computer  architecture  was  the  Burroughs  B5500  in  1961. 

The  B5500  used  the  concept  of  a hardware  stack  to  store  executable  statements  expressed 
in  reverse  Polish  notation  and  served  as  a predecessor  for  many  designs.  An  ALGOL  60 
design  described  by  Anderson  ( 10)  in  1961  was  an  extension  of  the  B5500  architecture  and 
consisted  of  three  stack  memories  and  pointers.  The  three  stacks  were  used  to  process  control 


I 


1 


states,  arithmetic  operators,  and  operands.  The  operator  stack  was  used  to  resolve  operator 
precedence  as  arithmetic  statements  were  interpreted.  Another  detailed  ALGOL  60  design 
was  formulated  by  Chu  in  1 973  (11).  The  functional  parts  of  Chu’s  ALGOL  computer  are 
shown  in  Figure  3.  The  partitioning  of  the  architecture  into  functional  elements  performing 
specific  operations  and  control  has  led  to  Chu’s  current  implementation  approach  using 
large-scale-integration  (6). 


Figure  3.  Functional  diagram  of  Chu’s  ALCJOL  computer. 
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Direct  execution  computer  architecture  work  in  the  I960’s  involved  several  languages 
including  F.ULER,  FORTRAN,  and  PL/1.  A significant  contribution  reported  in  1971  was 
the  design  and  construction  of  the  SYMBOL  computer  system  ( 1 2)  under  the  direction  of 
R.  Rice  and  W.  R.  Smith,  both  employed  by  Fairchild  at  the  time.  The  SYMBOL  architec- 
ture consisted  of  several  processors  interconnected  with  a main  bus  and  incorporated  a 
virtual  memory  allocated  automatically  by  hardware.  The  main  processing  parts  included: 

• central  processor 

• translator 

• interface  proce.ssor 

• memory  controller 

• memory  relaimer 

• disk  channel  processor 

• I/O  channel  controller 

• system  supervisor 

Figure  4 shows  the  SYMBOL  processors,  functions,  and  number  of  hardware  modules  per 
processor.  The  SYMBOL  high  level  language  is  a free  format  procedural  language  containing 
the  useful  features  of  FORTRAN,  ALGOL,  and  PL/1 . Absent  in  the  language  are  data  type 
and  size  declarations.  SYMBOL  was  implemented  using  small-scale-integration  (SSI)  12X17 
inch  single  layer  PC  boards  and  represents  a graphic  example  of  late  I960  SSI  technology. 
SYMBOL  was  donated  to  Iowa  State  University  in  1971  and  has  been  used  as  a research  tool. 
One  of  the  criticisms  of  SYMBOL  is  that  language  and  system  extensions  are  difficult  to 
implement  since  the  modules  are  hardwired.  In  addition,  the  SYMBOL  system  executes 
only  the  SYMBOL  language. 


PROCESSING  FUNCTIONS  SERVICE  FUNCTIONS 
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Figure  4.  SYMBOL  block  diagram. 
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Several  APL  designs  have  appeared  (13,  14,  15)  and  IBM  eurrently  oilers  the  5100 
desk-top  eomputer  that  executes  APL  or  BASIC  at  the  Hick  of  a front  panel  switch.  Other 
direct  execution  computer  architectures  which  have  emerged  are  SNOBOL  4,  HYDRA,  PL/1, 
and  IPL  processors  (9).  In  1967  Hawryszkiewycz  reported  on  a microprogrammed  system 
which  simulated  analog  computer  problems  ( 16).  At  least  one  interactive  simulation  language 
based  on  an  interpretive  translator  has  appeared,  however,  the  interpreter  is  written  in  mini- 
computer assembly  language  and  not  microprogrammed  (17).  (ieneral  Llectric  has  developed 
a set  of  hardware  microprocessor  modules  to  directly  execute  high  level  statements  for 
realtime  signal  processing  ( 1 8). 

The  sampling  of  direct  execution  computer  architecture  designs  reviewed  here  indi- 
cates a demonstrated  feasibility  for  directly  executing  a high  level  language  in  hardware 
and/or  firmware.  The  literature  shows  that  direct  execution  computer  architectures  have 
been  applied  to  both  general  purpose  and  specific  problem-orientated  languages.  It  should 
be  noted  that  the  more  recent  designs  (post  1970)  have  used  microprogramming  as  the  method 
of  implementing  the  functional  elements  of  a direct  execution  language.  This  approach  is  an 
advantage  to  the  designer  to  produce  flexible  firmware  which  can  be  easily  modified  during 
development  and  extended  when  future  language  expansion  is  required.  In  addition,  a direct 
execution  system  and  language  eliminates  the  need  for  multiple  system  programs,  such  as 
compilers,  assemblers,  and  linking  loaders.  As  a result,  the  user  interfaces  only  with  the  high 
level  language  and  its  execution  and  does  not  need  to  know  the  details  of  such  system  pro- 
grams. The  designs  reviewed  here  were  not  economical  to  build  in  the  technology  of  the 
1960’s  and  early  1970’s.  However,  current  large-scale-integration,  microprocessor,  and  memory 
technology  make  implementation  feasible  and  cost  effective.  These  advantages  and  others 
continue  to  emerge  as  research  in  direct  execution  architectures  and  directly  executable  high 
level  languages  progresses. 

DIRECT  EXECUTION  COMPUTER  ARCHITECTURES  FOR  SIMULATION 

I he  relationship  between  direct  execution  computer  architecture  concepts  and  con- 
tinuous system  simulation  should  be  examined  closely.  In  other  words,  why  apply  direct 
execution  to  simulation  and  at  what  level  should  it  be  applied?  It  is  a generally  accepted 
fact  that  direct  execution  systems  improve  the  interface  between  user,  iirogramming  language, 
and  application.  Interactive  model  development  and  problem  solution  are  particularly  im- 
portant in  contii.aous  system  simulation  since  these  factors  eventually  influence  designer 
efficiency  and  costs.  A direct  execution  system  allows  a simulation  language  user  to  inter- 
actively develop  models  since  there  is  no  need  to  wait  for  the  output  of  chained  system 
programs.  This  environment  means  less  software  layers  between  the  user  and  equipment. 
Large-scale-integration  implementation  of  a direct  execution  system  provides  a low-cost 
high-performance  alternative  to  existing  digital  and  analog-based  simulation  systems.  A 
microprogrammed  direct  execution  architecture  using  bipolar  technology  parts  can  be 
optimized  to  perform  specific  functions  required  in  continuous  system  simulation  problems. 
Such  an  optimized  combination  enables  basic  operation  times  as  low  as  200  nanoseconds  to 
be  achieved  and  provides  fast  execution  speeds  for  realtime  simulation  and  control.  The  low 
cost  characteristics  of  large-scale-integration  parts  translates  to  low  system  costs  and  makes 
possible  the  use  of  multiple  direct  execution  systems  in  distributed  simulation  .system 
architectures.  This  would  include  the  partitioning  of  large  problems  into  sections  executed 
by  a direct  execution  system  and  the  application  of  parallel  processing  integration  algo- 
rithms ( 19,  20).  Given  that  these  potential  advantages  exist,  the  levels  at  which  direct 
execution  concepts  can  be  applied  to  continuous  system  simulation  must  be  explored. 
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l-'irst,  1ft  us  examine  the  ciil't'ereiit  phases  of  interactive  continuous  system  simulation. 
I'igure  5 shows  the  processes  irwolveil  in  simulating  dynamic  systems  in  an  interactive  environ- 
ment. U.ser  interaction  with  t le  simulation  system  occurs  at  two  distinct  levels:  ( 1 ) problem 
preparation  and  documentation,  and  (2)  model  description  and  simulation.  Hath  ol  these 
levels  includes  the  several  related  (unctions  listed  here; 

1.  problem  preparation  and  documentation 

a.  text  editing  modirication  and  storage 

b.  report  preparation 

2.  model  description  and  simulation 

a.  model  dynamics 

b.  initial  conditions 

c.  procedural  and  .solution  control  sections 

d.  t'unctions  and  subroutines 

e.  run-time  execution 

r.  run-time  I/O  and  display 

g.  parameter  modification 

h.  post-run  display,  plotting,  and  processing 


Higure  5.  Continuous  system  simulation  process. 


A third  simulation  level  incltides  a realtime  environment  where  the  simulation  system  is 
dedicated  on-line  with  other  computer  equipment  or  actual  system  hardware.  Although 
user  interaction  is  minimal,  the  direct  execution  architecture  must  account  for  this  mode 
of  operation. 

Figure  b shows  the  various  phases  listed  above  partitioned  into  a direct  execution 
architecture  where  each  section  performs  a specific  function.  The  text  editing,  modification, 
and  storage  operations  are  easily  incorporated  by  a direct  execution  processor.  Since  user 
response  is  slow  during  these  phases,  the  processor  can  perfonn  a lexical  scan  and  syntax 
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Figure  6.  Direet  execution  computer  architecture  for  interactive  continuous  system  simulation. 


check  on  each  line  as  entered  by  the  user.  The  text  and  language  processor  can  perforin 
the  storage  and  retrieval  of  prepared  text  on  a disk  system.  As  the  user  enters  statements 
for  model  dynamics,  initial  conditions,  procedural  sections,  functions,  and  subroutines, 
the  same  processor  sets  up  ilata  structures,  stacks,  and  control  for  the  problem.  (This 
translation  process  is  further  discussed  below.)  These  items  are  stored  in  mulli|)ort 
memories  accessible  by  other  functional  processors. 

Run-time  execution  involves  the  solution  of  the  dynamic  system  equations  using 
standard  numerical  integration  techniques  for  differential  equations.  The  problem  stale 
variables  are  u|)dated  using  the  state  derivatives  and  siqrporting  equations  as  defined  by  the 
user.  This  set  of  ecjuations  is  translated  into  an  executable  form  in  the  multiport  memory.  | 

A direct  execution  processor  can  perform  the  run-time  solutions,  retrieving  and  storing  data  ,, 

Irom  the  multiiiort  memory.  A separate  I/O  and  post-run  processor  can  receive  interrupts 

from  the  direct  execution  processor  at  communication  interval  times  (usually  a subset  of  ■ 

the  solution-point  times)  so  that  data  can  be  displayed  or  stored  during  run-time.  Realtime 
data  and  control  can  be  handled  by  the  I/O  and  post-run  processor.  Post-run  display  and  ‘ 

processing  are  also  jrerformed  by  this  processor  by  retrieving  the  run-time  stored  data  from 

a high  s[)eed  disk.  The  user-defined  operations  to  be  performed  during  this  phase  are  also  I; 

stored  in  the  multiport  memory.  > 

The  translation  process  performs  two  main  functions.  First,  an  interpreter  processes 
all  language  statements  for  lexical  and  syntax  correctness.  The  interpreter  directly  sets  up 
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initial  conditions  by  assigning  memory  addresses  and  initializing  these  locations  with  data. 
The  interjireter  can  also  process  parameter  modification  statements  after  a run.  Second, 
model  dynamics,  procedural  and  solution  control  sections,  functions,  subroutines,  and 
post-run  statements  arc  processed  by  a mini-compiler.  The  compiler  places  an  intermediate 
code  in  the  multiport  memory  which  is  then  executed  by  the  direct  execution  processor. 

A compilation  process  is  used  here  (instead  of  an  interpretive  translation)  since  the  entire 
model  dynamics  section  must  be  present  to  obtain  a solution.  Using  this  approach  only  the 
initial  condition  section  must  be  retranslated  when  making  parameter  modifications  When 
a model  modification  is  made  the  entire  problem  must  he  reinterpreted  and  recompiled. 

The  initial  conditions  are  most  conveniently  expressed  by  the  user  using  an  equation- 
type  format.  The  model  dynamics  can  be  expressed  in  terms  of  equation  or  block-diagram 
oriented  language  constructs.  A typical  second-order  system  can  be  expressed  as  follows; 


Equation 

2)  Block-Diagram 

X'  =-A*X-B*Y 

MULTIPLY 

S = X*A 

Y'  = X 

MULTIPLY 

Q = Y*B 

INVERT 

Z = -S 

SUBTRACT 

P = Z-0 

INTEGRATE 

X=/P*G1 

INTEGRATE 

Y = / X*G2 

The  model  dynamics  lormat  described  here  determines  the  type  of  processing  that  is  used  by 
the  compiler.  For  example,  both  formats  can  be  easily  translated  into  a reverse  Polish  notation. 

Another  approach  is  to  use  an  intermediate  threaded-code  that  links  the  current  operation  to 
the  next  and  passes  parameter  addresses  and  data  through  stacks  and  lists.  In  each  case  the 
intermediate  code  is  executed  by  the  direct  execution  processor. 

Figure  6 pre.;ents  one  partitioning  scheme  for  a direct  execution  architecture  for 
simulation.  The  various  phases  ol  interactive  simulation  presented  in  the  paragraphs  above 
indicate  that  direct  execution  concepts  can  be  applied  to  the  problem  preparation  and  docu- 
mentation sections.  The  model  description  and  translation  phases  can  be  performed  by  a 
similar  processor  using  interpretation  and  compilation  techniques.  Run-time  execution  and 
I/O  operations  also  can  be  performed  by  a direct  execution  processor.  The  following  sections 
describe  the  sample  high  level  simulation  language  used  in  this  study  and  a la/ge-scale-integration 
implementation  of  a direct  execution  system  for  simulation.  ' 

DEMONSTRATION  VEHICLE:  MICRODARE  LANGUAGE  f 

I 

A high  level  simulation  language,  MICRODARE,  developed  by  Korn  (21)  and  Conley  (22)  I 

at  the  University  of  Arizona  was  chosen  as  the  vehicle  for  demonstrating  a direct  execution  i 

simulation  system  in  this  study.  MICRODARE  is  the  newest  of  a line  of  DARE  simulation 

languages  developed  under  Korn  (2).  Appendix  A summarizes  the  DARE  languages  which  in-  ^ 

elude  both  fixed-point  (block-diagram)  and  floating-point  (equation)  systems  that  run  on  a 

variety  of  large  mainframe  computers  and  minicomputers.  Most  of  the  DARE  systems  are  * » 

interactive  and  use  translators,  assemblers,  compilers,  and  linking  loaders  to  construct  a I 

run-time  object  program.  ' 
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MICRODARE  uses  system  software  derived  from  BASIC  and  does  not  require  an 
assembler,  compiler,  or  loader.  The  language  provides  interactive  program  entry,  editing, 
nie  manipulation,  and  multi-run  control.  The  two  main  sections  of  the  MICRODARE 
language  include:  ( 1 ) problem  initialization  and  run-time  control  and  (2)  problem  specifi- 
cation via  mathematical  and  realtime  operators.  Operators  are  implemented  in  efficient 
assembly  language  reentrant  threaded-code  subprograms  built  into  the  MIC  RODARE 
system  .software  or  in  LSI-1  1 microcode.  Appendix  B shows  the  operators  currently  avail- 
able. The  user  specifies  the  operators  (in  correct  computational  order)  for  problems  in 
dynamic  system  simulation,  signal  processing,  process  control,  and  laboratory  instrumen- 
tation. 

MICRODARE  uses  three  formats  of  data  words:  (1 ) 48-bit  floating-point,  32-bit 
mantissa;  (2)  16-bit  fixed-point  fractions,  and  (3)  16-bit  2’s  complement  integers.  The 
floating-point  data  is  a special  format  used  in  the  BASIC-dialect  portion  of  MIC’RODARE. 

Run-time  variables  are  converted  to  fractional  fixed-point  before  a run  and  reconverted  to 
floating-point  after  the  run.  MICRODARE  also  provides  for  run-time  display  of  problem 
variables  in  time  or  phase-plane  formats.  Additional  information  on  MICRODARE  is 
available  from  the  references  (2,  21, 22). 

MICRODARE  was  chosen  as  a demonstration  vehicle  for  direct  execution  for 
simulation  for  several  reasons.  First,  the  system  software  was  available  and  executing  on 
commercial  PDP-1  1 and  LSI-1 1 hardware  and  no  system  software  development  effort  was 
required.  Second,  MICRODARE  executes  on  LSI-1  1 microcomputer  systems  and  provides 
a low-cost  system  (under  S I 2K)  with  graphics  and  a capability  for  special  purpose  hardware 
interfaces.  Also,  the  LSl-1 1 bus  is  well  documented  and  can  be  easily  interfaced  to  custom 
devices.  Third,  the  MICRODARE  language  constructs  are  simple  and  implemented  in  modu- 
lar system  software  that  can  be  easily  modified.  Fourth,  MICRODARE  language  constructs 
allow  operations  in  a realtime  signal  proce.ssing  or  simulation  environment.  In  summary,  the 
MICRODARE  language  provided  an  excellent  opportunity  to  investigate  and  demonstrate 
the  application  of  direct  execution  computer  architectures  without  having  to  invest  a large 
amount  of  time  and  effort  in  starting  from  scratch  to  develop  new  language  specifications. 

The  MICRODARE  system  software  used  in  this  project  contains  a modified  BASIC 
interpreter  and  mini-compiler  that  generate  a threaded-code  list  of  block  operators  arid 

argument  addresses.  This  list  is  operated  on  the  LSl-1 1 which  executes  preprogrammed  , 

PDP-i  1 machine  language  instructions  instructions  for  each  operator.  Figure  7 shows  a simple 
data  acquisition  and  processing  example  and  the  threaded-code  address  list  generated  by  the 

MICRODARE  mini-compiler.  An  index  register  pointer  is  used  as  a “virtual  program  counter”  • I 

and  incremented  after  each  memory  reference.  Each  canned  operator  subprogram  contains  c 

a preindexed,  indirect,  and  increment  jump  instruction  which  provides  the  linkage  mechanism 

to  the  next  operator.  In  this  way,  fast  executing  subprograms  are  efficiently  and  simply  linked  I 

together. 

t. 

i' 
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ADC 

SUM 

MULT 


X 

P = X + B 
Y = P • A 


READ  A-D  CONVERTER 
ADD  B TO  X 

PERFORM  MULTIPLICATION 


THREADED-CODE  ADDRESS  LIST 


I ndex  j 

Register  ► AqC 

Pointer  / 


; Address  of  ADC  Handler 


X 

SUM 

X 

B 

P 

MULT 

P 

A 

Y 


; Address  of  Data  X 
; Address  of  SUM  Subroutine 


DATA  LIST 
X 
B 
P 
A 
Y 


I 


Figure  7.  MIC  RODARt  data  acquisitiun  example. 


f-ipure  8 shows  an  interactive  problem  simulating  a servo  mechanism  and  a mean- 
square-error  computation.  Appendix  C contains  additional  and  more  complex  MICRODARE 
sample  problems  including  a two-dimensional  torpedo  dynamics  simulation. 
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T 


E 


= U-X 


(servo  error) 


dX 

— =G1%*XD 

dT 


dXD 

= G2%  (H*E -R.XD) 

dT 


(servo  state  equations) 


(Mean  square  error) 


10  *****  ********************  A SIMPLE  SERVO  SIMULATION 

15  CLEAR  STACK  | 

20  DT=0.005  : TM=0.9999  : *****  SIMULATION  PARAMETERS  : 

30  Gl%=20  : G2%=40  ; G3%=10  : *****INTEGRAT0R  GAINS 

40  X=0  : XD=0  : P=0  : *****  INITIAL  VALUES  OF  STATE  VARIABLES 

45  H=0.375  : *****  A CONSTANT  PARAMETER 

50  U=0.8  : *****  INPUT  STEP  VALUE 

55  PRINT  "ENTER  DAMPING  PARAMETER  R" 

60  INPUT  R : *****  INPUT  INTERACTIVELY  REQUESTED  FROM  USER 
65  T=0 

70  DRUN  : *****  DIFFERENTIAL-EQUATION-SOLVING  RUN 
80  END 

90  *****  ********************  block-diagram  program  follows 

20100  DIF  E=U-X  t 

20200  MULT  RX=R*XD 

20300  MULT  HE=H*E 

20400  DIF  Y=HE-RX  ; 

20500  MULT  ES=E*E  l 

20550  *****  ************  RUN-TIME  DISPLAY  f 

20560  DISPT  X \ 

20570  DISPT  E ' 

20580  *****  ************  INTEGRATORS  ARE  LAST!  t. 

20600  INTG  XD(Y*G2%  j, 

20700  INTG  X(XD*G1%  [ 

20800  INTG  P(ES*G3%  : *****  MEAN-SQUARE  ERRQR  f 

) 

Figure  8.  MICRODARK  servo  mcchanisTn  example. 
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LSI  IMPLEMENTATION  OF  DIRECT  EXECUTION  MICRODARE 

A functional  partitioning  scheme  of  an  interactive  simulation  system  was  briefly 
depicted  in  Figure  6.  Depending  on  the  function  of  each  block,  one  can  assign  various 
large-scale-integration  devices  and  subsystem  hardware,  firmware,  and  software  to  perform 
the  specific  tasks.  Figure  9 shows  the  partitioning  scheme  as  applied  to  the  MICRODARE 
simulation  language.  A key  feature  of  the  scheme  used  here  was  the  separation  of  the 
problem  preparation  and  translation  functions  from  the  run-time  execution  of  the  problem. 
The  former  requires  moderate  execution  speed  while  the  latter  requires  high  speed. 


8 OR  16  BIT 
NMOS 

MICROCOMPUTER 

SYSTEM 


figure  9.  Direct  execution  aicliileclure  for  MICRODARE. 

t 

Low  cost  and  commercially  available  large-scale-integration  devices  and  subsystems  | 

were  considered  and  included  three  eomponent  types:  (1)8  and  16-bit  microprocessors;  (2) 
microprogrammed  bit-slice  devices;  and  (3)  high  speed  memory.  The  blocks  in  Figure  9 are  ^ 

repeated  here  with  the  type  of  large-scale-integration  devices  applicable  to  each  subsystem.  • | 

1.  Text  and  Language  Processor  | 

Eight  or  16-bit  n-channel  metal-cxide-semiconductor  microprocessor  with  local  ' | 

program  read-only-memory  and  data  random-access  memory.  Interfaces  to  user  terminal,  \ 

program  storage  lloppy  disk  subsystem,  and  multiport  memory.  Moderate  speed  micro-  ^ 

processor  (200-300  kilo-operations-per-second)  is  required  since  user  interface  is  typically  at 
human  response  times.  This  processor  also  performs  the  interpreter/compiler  functions. 
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2.  Multi-Port  Memory 

Hipli  speed  (50-200  nanosecond  access  time)  memory  configured  with  ports  to  the 
text  and  language  processor,  direct  execution  processor,  and  input/output  and  post-run 
processor.  The  direct  execution  processor  should  have  priority  over  the  other  two  since  it 
will  execute  much  faster.  However,  in  a realtime  environment,  the  input/output  processor 
might  ret|uire  a high  priority  for  rapid  data  transfers.  Memory  size  should  be  approximately 
16-32K  of  16-32  bit  words. 

3.  Direct  Execution  Processor 

Bipolar  bit-slice  components  including  register,  arithmetic  and  logical  units,  micro- 
program memory,  microprogram  sequencer  unit,  and  miscellaneous  circuitry.  This  processor 
must  have  the  capability  to  perform  microprogrammed  operations  such  as  multiplication, 
summation,  and  integration.  Special  functions  components  such  as  a multiplier  unit  and 
sine/cosine  read-only-memories  could  be  used  here. 

4.  Input/Output  and  Post-Run  Processor 

High  speed  1 6-bit  microprocessor  or  bipolar  bit-slice  components  with  architecture 
featuring  multiple  input/output  ports  to  memories,  realtime  devices,  and  high  speed  storage 
and  display  peripherals.  Post-run  processor  can  be  programmed  via  the  multiport  memory 
with  instructions  supplied  by  user. 

To  fully  implement  the  four  major  sections  described  above  using  a variety  of  large- 
scale-integration  devices  represented  a monumental  task  beyond  the  time  and  finances  available 
for  this  project.  Therefore,  a simplified  architecture  scheme  was  used  that  still  demonstrated 
direct  execution  concepts  for  simulation.  The  simplified  architecture  consists  of  a dual  pro- 
cessor system  interconnected  via  a dual  port  memory  as  shown  in  Figure  10.  The  functions 
ol  the  text  and  language  processor  and  the  input/output  processor  were  combined  and  imple- 
mented on  a LSI-1 1 microcomputer  system.  A dual  double-density  (loppy  disk  subsystem 
provides  program  and  run-time  storage.  A Tektronix  4006  graphics  terminal  provides  program 
entry  and  run-time  displays.  The  dual  port  memory  ( 16K  X 16)  is  part  of  the  total  (28K  X 16) 
LSl-l  1 memory.  The  MICRODARE  system  software  is  stored  on  the  lloppy  disk  system  and 
executes  in  the  LSl-1 1 and  dual  port  memory.  In  addition,  a bit-slice  microassembler  is  run 
on  the  LSI-i  I to  develop  microcode  software  for  the  direct  execution  processor  (23). 


In  the  dual  processor  architecture  depicted  in  Figure  10,  the  user  inputs  the  MICRO- 
DARF.  problem  via  the  Tektronix  4006  terminal.  The  MICRODARE  system  software  tran.s- 
lates  the  problem  into  an  intermediate  threaded-code  that  consists  of  an  operation  and  data  ' 

address  list  tor  the  dynamics  stale  variable  computations  and  numerical  integration.  The  ^ 

address  list  and  corresponding  data  locations  are  stored  in  the  dual  port  memory.  Once  the  ^ 

dual  port  memory  contains  this  threaded-code,  the  LSl-1  1 begins  the  simulation  run.  The  i 

LSl-l  1 signals  the  direct  execution  processor  to  start  its  processing.  The  direct  execution  i 

processor  tetches  the  operation  opcodes  and  data  operands,  performs  the  operation,  stores  j, 

the  result,  and  links  to  the  next  operation.  After  the  last  operation  is  performed,  the  direct 

execution  processor  returns  control  back  to  the  LSI-1 1 which  performs  numerical  integration  f 

of  the  stated  variables  and  displays  the  selected  variables  on  the  graphics  terminal.  The  LSl-l  1 
also  performs  simulation-study  control  and  pre-run  and  post-run  computations.  Eventually,  1, 

the  direct  execution  processor  will  perform  all  of  the  numerical  integration  and  realtime  in- 
put/output. The  following  sections  further  describe  the  components  and  operation  of  the 


dual  port  memory,  direct  execution  processor,  and  writeable  control  store  and  their  interaction 
with  the  LSl-l  I as  shown  in  Figure  1 1. 
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Figure  10.  MICRODARE  dual  processor  system. 
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MICRODARE  INTERPRETER 
SETS  UP  THREADED  CODE 
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ADC 
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X 

Y 
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Figure  1 1.  Dual  processor  operation  for  MICRODARE. 
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The  dual  port  memory  provides  a path  of  eomimmication  between  tlie  LSl-1 1 and 
the  direct  execution  processor  (l)EP).  As  seen  by  the  LSI- 1 I , the  dual  port  memory  looks  ' 

like  an  ordinary  LSl-1 1 16K  memory  circuit  board.  As  seen  by  the  DEP,  the  dual  port 
memory  looks  like  an  8K  word  by  32-bit  memory.  The  memory  is  electrically  configured 
as  an  array  of  8K  X 32-bit  words  with  multiplexers  to  enable  reading  and  writing  8-,  16-,  or 
32-bit  words.  This  feature  is  required  because  the  LSI-1 1 must  have  8-  or  16-bit  read/write 
capability  while  the  DEP  requires  16-  or  32-bit  read/write  capability.  The  electrical  speci- 
fications governing  the  use  of  the  LSI-1 1 port  are  identical  to  the  normal  “0-BUS”  speci- 
fications found  in  the  LSTI  I technical  manual  (24).  The  DEP  port,  however,  is  not  standard 
and  consists  of  the  following: 

1.  13  address  lines  (ADD) 

2.  32  data  lines  (bidirectional) 

3.  A write  (read  not)  command  line  (W) 

4.  A half  (whole  not)  word  command  line  (HW) 

5.  A memory  request  line  (MR) 

6.  A memory  acknowledge  line  (from  memory)  (RA) 

7.  A read  data  ready  line  (DR) 

Note;  The  above  lines  are  low  true. 

The  operation  ol  the  DEP  port  is  as  follows,  and  its  timing  diagram  is  shown  in  Figure  1 2. 

t 

1.  Read  Operation  i 

- The  DEP  asserts  the  address  (ADD)  and  negates  the  write  (W)  and  half 
work  (HW)  signals. 

- Memory  recpiest  (MR)  is  then  asserted. 

- The  memory  sends  request  acknowledge  (RA)  when  the  DEP  port  gains  access. 

- After  the  read  access  delay  the  data  is  placed  on  the  lines. 

- The  true  to  false  transition  of  data  ready  (DR)  should  be  used  to  strobe 

the  data.  i 

I 

- The  DEP  then  negates  memory  request  (MR). 

2.  Write  Operation  ' 

- The  DEP  asserts  the  address  and  write  signal  (W)  and  negates  the  half  ' 

word  (HW)  signal.  * 

- Memory  request  (MR)  is  asserted.  tj. 

- The  memory  sends  request  acknowledge  (RA)  when  port  access  is  granted.  r 

- The  DEP  places  write  data  on  the  data  lines.  i 

- After  data  has  been  stable  on  the  lines  for  10  nsec  the  write  signal  (W)  is  ' . 

negated  (assertion  can  happen  anytime).  E 

- Memory  retjuest  (MR)  is  then  negated.  (*■ 

Assertion  of  the  half  word  command  (HW)  causes  the  above  operation  to  be  performed  on  a [ 

half  rather  than  whole  word.  When  half  word  mode  is  selected,  the  least  significant  address  ^ 

bit  indicates  which  half  ol  the  word  is  to  be  used.  This  is  also  the  convention  followed  in 
byte  mode  using  the  LSI-1  1 port. 
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Figure  12.  Dual  port  memory  timing  diagram  (DEP  port). 


The  direct  execution  processor  (DEP)  functional  block  diagram  is  shown  in  Figure  13 
and  is  implemented  using  the  Advanced  Micro  Devices  2900  bit-slice  family  of  parts  (24).  The 
DEP  consists  of  a data  processing  section  and  a microinstruction  sequ.  ncer  section.  These 
sections  include  the  following  functional  parts: 

1.  32-bit  data  read/write  interface  to  dual  port  memory. 

2.  32-bit  AMD  2903  register,  arithmetic,  and  logical  unit  (RALU). 

3.  16  X 16  TRW  multiplier  unit. 

4.  1 6-bit  AMD  2930  memory  address  controller.  t 

5.  AMD  2910  microsequence  controller.  I 

6.  IK  X (i4-bit  writeable  control  store  memory  and  pipeline  register. 

7.  10-bit  operation  code  (instruction)  register. 

H.  32-bit  memory  data  register  with  selectable  16-bit  upper  and  lower  sections.  . j. 

9.  1 6-bit  memory  address  register  to  dual  port  memory. 

10.  Status  register  and  condition  code  multiplexer. 

1 1 . Direct  data  paths  from  memory  data  register  to  memory  address  register. 

12.  Data  path  from  pipeline  register  to  32-bit  RALU. 

13.  System  clock  circuitry,  approximately  !>  MHz. 


16 


I 


14.  Control  lines  to  dual  port  memory. 

15.  Mieroprograms  tor  MICRODARH  operations. 

These  parts  are  wire-wrapped  on  two  quad-type  boards  similar  to  LSI-1 1 boards. 

TO  DUAL  PORT  MEMORY 


DEP  AND  DPM 
CONTROL 


FiMure  13.  Direct  Execution  Processor  (DEP)  functional  block  diagram. 

The  LSl-1 1 and  direct  execution  processor  communicate  through  an  absolute  “mailbox” 
address  virtual  program  counter  (VPC)  in  the  dual  port  memory.  The  direct  execution  pro- 
cessor periodically  examines  the  VPC  location,  commences  its  operation  if  the  LSI- 1 i program 
has  set  the  word  to  a microcode  address,  and  puts  the  LSI-1 1 in  a wait  mode.  Figure  14  shows 
the  sequence  for  an  ADD  operation  by  the  direct  execution  processor.  For  details,  the  reader 
is  referred  to  the  internal  architecture  of  the  AMD  2903  and  2930  parts  (25,  26).  Notice  that 
the  32-bit  interface  to  the  dual  port  memory  allows  reading  of  (1)  an  operation  code  and  data 
address  or  (2)  two  data  addresses  from  the  threaded-code  list.  Data  is  read  and  stored  in  the 
memory  as  16-bit  2’s  complement  fixed-point  fractions.  All  MICRODARF  operations,  except 
MULTIPLY,  are  performed  by  the  2903  RALU.  When  the  operation  is  complete,  the  direct 
execution  processor  stores  the  update  virtual  program  counter  in  VPC  and  enters  a wait  loop. 
The  LSI-1 1 reads  this  address  in  VPC  as  a threaded-code  address  and  continues  with  the  display 
operations.  Further  details  and  speed  benchmarks  will  be  documented  in  future  reports. 
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MAR 

•4 PC 

/Address  of  Operator/Data  Address/Pair 

2 

MDR 

■4 DPM(MAR);  PC  4—  PC  + 2 

3. 

IR 

4 '“'Df’wSB'  PUSHMDR^^gg;  MAR 

◄ PC/ 

4. 

MDR 

4 DPMIMARI;  PC  ♦—PC  + 2 

/Address  of  Data  Address  Pair 

5 

MAR 

♦ — MDRmsB'  PUSHMDRlsb 

6 

♦ DPMIMAR) 

/First  Operand 

7. 

RAM(B) 

♦ 

8. 

'^°'’msb 

♦ DPMiMAR) 

/Second  Operand 

9 

RAMIAI 

♦ POP 

/Add  Operands 

10. 

DPMIMARI 

♦—  RAMIA) 

/Store  Result 

MAR:  Memory  Address  Register 
MOR  Memory  Data  Register 
IR  Instiuction  Register 
DPM  Dual  Port  Memory 


RAM;  2903  RAM 
PC:  2930  Program  Counter 
PUSH/POP:  2930  Stack 
A/B:  2903  RAM  Address 


Figure  14.  Sequence  lor  ADD  operation  in  Direct  Execution  Processor. 

I'he  direct  execution  processor  contains  a microinstruction  sequencer  section  which  con- 
tains an  AMI)  2910  microscquence  controller  and  a writeable  control  store  memory  which  con- 
tains microcode  lor  MICRODARH  operations.  Details  of  the  microsequencer  are  referred  to 
the  AMI)  2910  literature  (2.S).  The  writeable  control  store  board  consists  of  the  control  store 
memory,  the  system  clock,  and  a parallel  I/O  interface  to  the  LSl-1 1.  Figure  15  is  a block  diagram 


Figure  I.S.  Writeable  control  store  block  diagram. 
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of  the  board.  The  control  store  consists  of  IK  X 64  bits  of' higlt  speed  RAM.  Ten  address 
lines.  NXTINSTADDR,  from  the  backplane  select  the  next  microinstruction,  NXTINST, 
which  is  buffered  onto  the  backplane.  Acce.ss  time  of  the  RAM  is  45  ns.  Also  supplied  to 
the  backplane  is  the  5.0  MHz  system  clock  and  a disable  signal,  MPSHQDIS.  When 
MPSTOHIS  is  high,  the  writeable  control  store  is  being  addressed  by  the  LSl-i  I and 
NXTINSTADDR  should  be  disabled  (high  impedance  state). 

The  LSI- 1 1 can  read  or  write  the  control  store  via  a DRV-1  1 parallel  interface.  Control 
store  addresses  and  data  are  transmitted  in  successive  16-bit  words,  one  word  for  the  addre.ss 
and  four  words  for  a complete  microinstruction.  The  two  control  lines.  CSRO  and  CSR 1 , 
from  the  DRV-1  1 are  used  to  direct  the  I/O.  CSRO  describes  the  contents  of  the  data  lines. 
OUT  0TO15.  CSRO  low  indicates  control  store  address  and  initiates  the  read/write  sequence; 
high  indicates  control  store  data.  The  least  significant  16  bits  are  transmitted  first.  Low  CSR  I 
at  the  time  the  addre.ss  is  loaded  (CSRO  low)  directs  the  logic  to  load  the  contents  of  the 
control  store  into  the  output  register,  DOREG,  for  subsequent  multiplexing  onto  the  IN  ()  rOI5 
lines  to  the  DRV-1  I . A high  CSR  I indicates  a write  sequence  which  is  initiated  after  the  input 
data  register,  DIREG,  is  loaded.  REQB  is  used  as  an  interrupt  signal  for  interrupt  driven  I/O 
by  LSl-1  1.  An  interrupt  is  generated  by  the  completion  of  write  or  read  cycle.  RL(,)A  provides 
a ready  signal  for  the  LSI-1 1 . It  is  reset  during  access  to  the  control  store.  AINIT  or  BINIT 
initializes  the  I/O  logic. 

The  LSl-1  1 microcomputer  system  shown  in  Figure  10  is  an  off-the-shelf  system  which 
executes  the  MICRODARE  system  software.  The  LSI-1 1 has  a 28K  16-bit  word  memory 
space.  16K  of  which  is  the  dual  port  memory.  Other  functional  elements  oi  the  LSl-l  1 system 
include: 


1 LSI-1  1 mkrocompiilcr  module  with  extended  instruction  set  and  lloaling 
point  chips. 

2.  28K  ( 16-bit)  semiconductor  memory,  16K  dual  jrort  to  DEP. 

3.  Dual  double  density  floppy  disk  drive/controllcr  with  UNIBUS/LSI-1  I 
converter  interface. 

4.  Multi-slot  backplane  and  power  supply. 

5.  RT-1  I floppy  disk  operating  system  and  MICRODARE  system  software. 

6.  ElA  RS-232  serial  interface  module  to  terminal. 

7.  Panel,  clock,  and  terminator  module. 

8.  (iraphics  terminal  with  keyboard  entry. 

d.  Decwriter  III  line  printer/terminal. 

10.  Parallel  interface  module  to  writeable  control  store  memory. 

I he  memory  layout  for  the  dual  processor  system  is  shown  in  Figure  16.  Additional  details 
on  the  MICRODARE.  systems  software  can  be  found  in  the  references  (21,  22). 

I he  R F-l  1 operating  system  resides  on  diskettes  for  a double  density  dual  floppy 
disk  system.  RE-l  1 incfudes  a monitor,  PIP  utilities,  text  editor,  microassembler,  BASIC, 
FORTRAN  compiler,  linking  loader,  and  device  handlers.  The  application  programs  used 
here  were  MICRODARE/  simulation  language  and  AMDASM  microassembler.  The  MICRO- 
DARE, system  is  a stand  alone  program  that  can  be  run  by  typing  R MDTEK  on  the  control 
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Mgure  16.  Memory  layout  tor  MICRODARE  dual  processor  system. 


terminal.  MICRODARE  is  a modified  BASIC  interpreter  and  lias  botli  file  manipulation 
and  text  editing  capabilities.  Some  minor  moditleations  to  this  software  have  been  made 
(22).  The  MieroTee  A.MDASM  mieroa.ssembler  program  is  u.sed  to  develop  microcode  for 
LSI  bit-slice  devices,  such  as  the  2900  family  (23).  The  program  is  written  in  FORTRAN 
and  requires  a FOR  I RAN  compiler  in  order  to  run  on  the  LSI-1  I microcomputer  system. 
The  microassembler  was  installed  as  three  stand-alone  programs  under  R'1-1 1 and  can  be 
invoked  by  typing  R AMDASM.  AMDASM  is  used  to  develop  microcode  for  the  direct 
execution  processor.  The  input  to  AMDASM  is  a source  file  containing  microprogram 
field  declarations,  variables,  and  mnemonics.  The  AMDASM  object  output  is  stored  on 
a disk  file  and  later  transferred  to  the  writeable  control  store  memory. 

APPLICATION  AREAS  FOR  DIRECT  EXECUTION  ARCHITECTURES 

Simulation  of  continuous  systems  is  a prime  example  of  an  application  area  for  direct 
execution  computer  architecture.  In  an  interactive  simulation  environment,  the  user  must 
make  model  and  parameter  changes  to  the  problem  and  quickly  evaluate  the  results  of  the 
new  simulation.  He  cannot  afford  (nor  his  employer)  to  wait  for  lengthy  compilations  and 
library  linkages  to  produce  an  executable  simulation  run.  Direct  execution  computer 
architectures  provide  the  close  relationship  between  the  user  and  the  simulation  equipment 
required  in  this  type  of  application  problem.  An  additional  advantage  is  increased  compu- 
tation speed  since  the  architecture  is  optimized  to  numerically  solve  systems  of  differential 
equations.  This  advantage  becomes  important  in  a realtime  data-acquisition  or  simulation 
problem  where  an  analog  computer  is  to  be  replaced.  Once  the  model  has  been  developed 
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the  problem  state  variables  are  computed  via  microprogrammed  operations  stored  in  read- 
only-memory. Clearly  such  a simulation  system  has  a limited  bandwidth  depending  on  the 
problem  time  constants  and  complexity.  However,  techniques  exist  to  partition  systems 
of  differential  equations  into  “slow”  and  “fast”  portions  by  separation  of  state  derivative 
equations.  In  addition,  algorithms  for  parallel  solution  of  differential  equations  have  been 
investigated  (20,  27)  and  can  be  adapted  into  direct  execution  architectures,  in  these  types 
of  problems,  the  direct  execution  architecture  described  in  this  paper  has  extei’^ions  to 
multiprocessor  simulation  systems. 

Direct  execution  architectures  can  be  applied  to  problems  that  require  a close  user/ 
equipment  interface.  Laboratory  process  and  instrumentation  control  is  an  example  where 
data  acquisition,  distribution,  and  signal  processing  can  be  performed  with  a direct  execution 
system.  Interactive  languages  for  graphics  display  systems  which  require  a small  amount  of 
data  formatting  and  processing  prior  to  displaying  can  utilize  direct  execution  concepts. 

Data  base  management  systems  that  require  information  storage  and  retrieval  functions  are 
applications  areas  of  direct  execution  concepts  (28).  All  ot  these  application  areas  retjuire 
subsystem  control  and  data  inquiries  which  can  be  performed  quickly  and  without  recom- 
piling when  a model  change  is  made. 

The  traditional  application  area  for  direct  execution  architectures  has  been  general 
purpose  high  level  programming  languages.  Direct  execution  architectures  are  continuing 
to  emerge  for  languages  such  as  BASIC  and  APL.  A stack-oriented  16-bit  microcomputer 

chip  set  which  interprets  PASCAL  intermediate  P-code  in  hardware  has  been  announced  , 

by  Western  Digital  ( 29).  Other  semiconductor  vendors  are  reportedly  working  on  similar  | 

microcomputer  architectures. 

SUMMARY  AND  CONCLUSIONS 

The  concepts  of  direct  execution  computer  architecture  for  continuous  system 
simulation  investigated  under  this  project  fall  into  two  categories:  ( 1 ) interactive  develop- 
ment mode  and  (2)  realtime  computation  mode.  The  first  category  involves  the  high  level 
language  issues  and  the  interface  to  the  direct  execution  hardware.  The  second  category 
relates  to  the  direct  execution  architecture  and  its  capability  to  perform  high  speed  com- 
putations. 

User  requirements  in  the  interactive  development  mode  clearly  indicate  the  ad- 
vantages of  an  interpreter-based  language  over  a compiler-based  language.  The  interpreter 
instantaneously  reports  back  errors  to  the  user  as  he  enters  language  statements.  In  the 
case  of  MICRODARh,  a combination  of  interpreter  and  compiler  is  suitable  since  the 

numerical  solution  of  differential  equations  involves  repeated  computation  ot  the  problem  / 

state  derivatives.  The  MICRODARL  mini-compiler  sets  up  a threaded-code  list  for  the  f 

simulation  run  which  is  executed  by  the  microprogrammed  direct  execution  processor.  I 

Language  extensions  to  MICRODARH,  such  as  the  addition  of  special  purpose  mathematical  > 

• functions,  can  be  made  by  adding  the  appropriate  microcode  or  hardware  units.  Although 

the  MICROF^ARH  interpreter  is  derived  from  BASIC,  it  is  coded  in  PDP-1 1 assembly 

language  and  executes  fairly  rapidly  on  a minicomputer  (less  than  2 seconds  lor  most  (* 

problems).  The  MICRODARH  interpreter/compiler  would  execute  still  faster  if  some  of  | 

the  assembly  language  subroutines  and  functions  could  be  microcoded.  The  new  LSl-1 1 j 

module  with  writeable  control  store  memory  can  provide  this  teature.  A',sembly  language 
modifications  were  made  to  the  interpreter  software  in  this  project  to  accommodate  trans- 
i ferring  parameters  through  the  dual  port  memory  to  the  direct  execution  processor. 
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The  a-altinic  coniputation  mode  is  necessary  if  the  direct  execution  system  is  to  be 
used  to  solve  systems  of  differential  equations  on-line.  Replacement  of  analog  computer 
functions  in  a hybrid  .simulation  system  is  such  an  example.  In  this  project,  high  speed  bit- 
slice  devices  provided  the  means  of  demonstrating  the  direct  execution  architecture.  The 
llexibility  of  these  parts  enable  an  optimized  design  to  retrieve,  compute,  and  store  simu- 
lation variables  in  the  dual  port  memory.  The  partitioning  scheme  used  enforced  the 
need  for  special  purpose  LSI  units,  such  as  multiport  memories,  multipliers,  sine/cosine 
ROM,  memory  addre.ss  controllers,  and  lloating  point  processors.  The  units  provide  high 
speed  processing  which  would  normally  be  performed  by  the  LSl-1  1 or  in  direct  execution 
processor  microcode.  Additional  units  to  speed  up  the  language  interpreter  sections  could 
be  used  if  available.  The  partitioning  scheme  also  pointed  out  the  advantages  of  independent 
parallel  data  and  address  processing  sections  in  the  design.  The  data  processing  section  in 
this  project  used  16-bit  Hxed  point  fractional  arithmetic.  This  approach  requires  the  user 
to  scale  the  simulation  problems  as  in  the  analog  computer  style.  A floating  point  architec- 
ture would  negate  this  requirement. 

Investigations  in  this  project  indicated  potential  future  work  amas  in  direct  execution 
architectures  for  simulation.  These  areas  are  summarized  here: 

1.  Multiport  Memory  LSI  Chips  high  speed  devices  to  develop  low  cost  memories 
for  interprocessor  communication. 

2.  Lloating  Point  Direct  Kxecution  System  enables  scale-free  simulation 
problems;  separate  data  and  program  memories. 

3.  High  Speed  LSI  Lloating  Point  Processor  — multi-chip  bipolar  or  SOS 
processor  to  complement  floating  point  system;  existing  NMOS  processor  is  too  slow. 

4.  Optimized  Interpreter  for  Simulation  - translation  phase  of  simulation 
described  earlier  in  report  and  is  optimized  to  process  simulation  statement  constructs. 

5.  Input/Output  Interfaces  for  Direct  Execution  Process  — design  with  capability 
to  interface  to  other  direct  execution  processors  to  handle  large  simulations. 

6.  Direct  Execution  Multiprocessor  System  Software  — system  software  to  handle 
multiprocessor  simulation  possibly  based  on  concurrent  PASCAL  concepts. 

7.  Special  Function  LSI  Units  high  speed  function  table  look-up  units, 
sine/cosine  ROMs,  exponential  and  transcendental  functions,  string  processing  operators, 
and  memory  stacks  are  examples  of  these. 
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APPENDIX  A 


Table  A 1 . DARK  languages  summary. 


DARK 

^sSystem 

Feature 

DARK-1 

1969 

DARK-11 

1970 

DARK-IIIB 

1971 

DARKP 

1973 

DARE/ELEVEN 

1974 

MICRODARE 

1977 

Computer 

System 

DKC  PDP-9 

DKC  PDP-9 

CDC6400/ 
DKC  PDP-9 

CDC6400, 
IBM  360, 
UNIVAC 

11 10,  etc. 

PDP-I I Family 

PDP-11 
Family  and 
LSI- 11 

Problem 

Representation 

Kquation 

Block 

Kquation 

Kquation 

Equation  & 
Block 

Block 

Data  Type 

48-Bit 

Floating  Point 

18-Bit 
Fixed  Point 

48  & 60-Bit 
Floating 
Point 

36-60  Bit 
Floating 
Point 

32-Bit 

Floating  Point 
& 16-Bit  Fixed 
Point 

16-Bit 

Fixed  Point 

Mode  of 
Operation 

Interactive 

Interactive 

Interactive 

Batch 

Batch 

Interactive 

Interactive 

t 

t 

f 

f 
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APPENDIX  B 

DARE  BLOCK-OPERATORS  USED  BY  MICRODARE 
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* SUMZ  = X + Y 

DIV  Z = X/Y 

* DIF  Z = X - Y 

* IMULTZ  = X *#n 

* MULT  Z = X * Y 

* NEC  Z(X 

z = -x 

* ABSVZtX 

N 

II 

X 

* LIMZtX 

Z = max  (X,  0)  / 

PL(x-y  >0) 

COMPZ(X-Y,  PL,  Ml 

Z = 

1 

Ml  (X-Y  <0) 

1 

[ -X(CT<0) 

SMULTZtX,  CT 

z = 

1 

1 

X (CT  > 0) 


TRICC;  Z(X,  zo 

Schmitt-t rigger  transfer  characteristic 

* FUNCTZ=Y(X 

table-lookup  and  interpolation  in  array  Y 

* INTC  Z(X  * C7r 

intergrator  with  integer  gain  Ci% 

SHOLD  Z(CT,  X 

sample  hold ; Z tracks  X if  CT  > 0 

UDELAY  Z (ZO,  (T,  X 

unit  delay  between  ZO  and  Z;  ZO  tracks  X if  CT  > 0 

SWEEP  Z 

sweep  waveform  (-1  to  1 ) 

SAW  Z(#n 

sawtooth  sweep,  frequency  n 

PULSE  Z(CT,#n,TD 

CT  > 0 generates  n pulses  TD  units  apart 

NOISE  Z(#n,  CT.  #m 

shift-register  pseudo-random  noise  generator 

STORE  AA  = X 

( stores  time  history  of  X 

STCKiET  AA  = X 

\ in  array  AA 

CET  X = AA 

produces  time  history  X from  array  A A 

TERM  X < Y 

terminates  DRUN  when  X < Y 

DISIT  X 

displays  X versus  T 

DISPXY  X,  Y 

displays  Y versus  X 

PROB  Z(X,  RS,  WR,  CT 

amplitude-distribution  analyzer 

’Microcode  currently  developed  for  Direct  Execution  Processor. 
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APPENDIX  C.  MICRODAPE  SAMPLE  PROGRAMS 

C.1  Two-Dimensional  Torpedo  L . iiiiTilcs  Example.’  by  R.  H.  Hidinger  NOSC  6353 
LI5T 


!3  CLEkIK:  STt^CK 

11  HP  = 200-  HUMBER  OP  POiMTS 

12  DIM  CXCHP3,0YCHP3,QUCHP3-C'PL'NP3 

20  DT  = 0.00005  tft*-*-  TIME  IHCP.  TINE  SChLE  lOOr'DTrrO  085; 

20  = e.3?  ttUi  MhX  time,  time  SC8LE  100  CTMh;!  = 100  S ; 

35  Cn  = TIVCHPTDT; 

■JO  iMTt  RUM  C0HSTAHT5 

50  UC  - 0 25  tttn  REL  TO  50  M-'S 

50  DIM  RTC1293  T4MT  RUDDER  COMMAND  TABLE,  PC.  = 20  DEC. 

55  FOP  I = 1 TO  12S  PT  = 0.0  NEXT  I ttttt  ZERO  TABLE 

70  PTt773  = 0.25:  RTC733  = 0 25  PTC7’ii3  O 25  RTC-383  =0  25  *1 

F 

72  RTCS53  = -0  25  PTC903  = 0.25:  RTC953  = -0.25=  RTE1O03  = 0 2‘ 

73  PTC1053  = -0  25=  RTCU03  = 0 25  TH-tR  SHAKE 

76  RTC1123  = -0  125  Itttt  ATTACK 

90  t»*<*  OU/OT  CONJTaHTS 

100  Xl  = 0 8155 

lin  y.2  = 0 3155 

120  UT  = XMUCTUC 

120  tni*  0Y,DT  CONSTANTS 

140  VI  = -0.9.9129 

150  Y2  = -8  04561 

160  Y2  = 0 12501 

170  ittn  DP'DT  CONSTANTS 

180  HI  = -8  96703 

190  N2  = -0  44866 

200  M3  = -0  77652 

210  U*lt  POTATION  SCALE 

220  RS  = 0 5 

2 50  niU  SIN  AMO  1.05 1 HE  TABIES 

231  DIM  SU10253,CSI.1O2O3 

235  PM  = 4*3.1415927  itftt  MAX  BEARING,  P 

2-10  FOR  I = I TO  1025 


2 = 0 A = 2tF(M024H-fpri+2t.PM,  1024)  »*»**  -PM-' =A'' =Pri 

260  JlCn  = SIH(A'  CSCI3  = COi.'A) 

270  HEI-iT  I 

2.=0  HU’*  INTEGRATION  CONSTANTS 

TOC  tin*  TIME  SChLE  = 100 

,710  c'l:;  = inn 

320  C"',  = iF.nn 

3.30  OR’,;  = 10000 

340  CF;,  = 25 

350  GX-.  ■=  10 

360  ijV;  = 10 

400  44*44  INITIAL  CONDITIONS 

4 1 0 'J  = 0 0 

420  U = n fl 

430  p = 0 0 

440  P = 0 A 

450  X = 0 0 

460  i = 00 

1008  44414  GO! 

1010  DR!  IN 
2000  END 

20000  41444  44.>4444444t4«4  44.444444t4»»444 

2010"?  *4444  4 2D  CONSTANT  COEFFICIENT  TORPEDO 

20280  44444  44444*4*4444444*4444444444444 

20210  *4444  STATE  UAPIAELES 

2021  1 44444  U FORWARD  UELOCITY  IN  TORPEDO  FRAME,  <50ri/S 

20212  44*44  U CROSS  UELOCITY  IN  TORPEDO  FRAME,  < 50M/S 

2021.3  444*4  R ANGULAR  RATE  AROUHO  TORP  2 AXIS,  <PI  RAO,S 

2021-4  44444  P BEAPIMr.  IN  INERTIAL  FRAME,  <4PI  RAD 

jiizr  44  414  y.Y  FosirioM  in  inertial  frame,  <1000 


444  riRCL 
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I02?0 

itiM  ntittttnt*f$iimttntt»nttu*:n*utntnutxt*u*ttfi 

2Sy  ^5 

FUMC  PD^P;T<.T 

M.t*t 

liYc-.h 

MUir  L!2=IJ»IJ 

ttltj  DU''DT 

MULT  iJS^XStUS 

23?5D 

MULT  :>!D=XC*PS 

•;!lEc  DU=IJT-IJS 

:-?ooo 

SUB  OX=XB-XD 

,vi7nn 

tlUt  jOriE  CP0?5  PRODUCTS 

'4010 

MULT  YrtsUtSP 

MULT  UIJ-U4.U 

24015 

MULT  Ye=Y0*ftS 

MUi-T  PU=R1U 

24020 

MULT  YC--UtCP 

MULT  Tl.i=PP*U2 

24025 

MULT  YD='YC»RS 

Mi  tt  DU  'DT 

24030 

SUN  OY=YB+YD 

1!  iOC* 

MULT  TMYUUU 

24100 

ttttt  UtX  INTEGRATION 

<:i20>3 

MULT  T2=Y2tRiJ 

24200 

INTO  Ui  OUfGU‘4 

w i7^’0 

TUiLT  T?=Y?tTU 

24300 

INTG  Ui'DUtGUX 

? 1 .;pri 

SUM  T4=TltT2 

24400 

INTG  RTDPtGRT. 

SUM  riU=T4+r7. 

24410 

IKTG  FXRtGPX 

:■ : f.M**': 

ttiM  DR/DT 

24420 

INTG  XXDXtGX'-. 

,^!7eC 

MULT  TSutUt'iU 

24430 

IMTC  Yv'DYiGYX 

MULT  TS=H2»PIJ 

24500 

tttti 

b-’i-OC 

MULT  T7=U31TU 

24700 

DISPXY  X.V 

-.M'-no 

SUN  TS-rS+TS 

iiioo 

SUM  DR=18+T7 

2S1?0 

MiM  SHKP.ftND  COS<P) 

ijfoe 

r. SP^SKP 

221i>C 

P'JUC  CP=CSTP 

i'jrrn'i 

MM1  ItlERTlPL  STi4TE  EQHS 

OX/DT.DY/OT 

: - Mf; 

MULT  XH=iJtCP 

.'  ?■■  '■(■' 

MULT  /B-yntPS 

^ ;.  '1111 

liHI  T y.r.-Ut-J- 

Two-Dirensional  Tor-'or;©  Exanple 
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C.2  Parameter  Optimization  Problem:  by  G.  A.  Korn,  University  of  Arizona 


2300 

T=0  0 

2400 

PRINT  12 

50 

CLEOR  STOCK 

10000 

OPIJN 

*^5 

P=  4 

11000 

OX=0X->CC';»UX 

60 

DIM  FFC333 

12000 

0Y=0Y+GG2»UV 

FOP  j;;=l  TO  15  FFCJ7.]=-P  = 

NEXT 

Jt-3000 

TX=T;!-GG2I0X 

66 

FFE163=-P'2^  FFC133=P/2 

14000 

TY=TY-GG2«0Y 

67 

FFC173=0.0 

15000 

NEXT  r. 

63  1 

FOP  J3=13  TO  iZ-  FF[J'4D=P 

NEXT 

.t?090 

PRINT  TK.0  5.TY,0  510 

IOC 

0T=0  01 

1910V3 

END 

TI1=  9 

20100 

MULT  YD=V1h 

700 

r.:;-:=-6 

20200 

MULT  X3=X!;iTX 

4 00 

GY-;--6 

20300 

MULT  YS=VY4TV 

450 

G‘.=  l 

20400 

SUM  S=a+Y 

460 

GGi;=2 

20410 

MULT  XT=X:-;*0X 

500 

0=  7 

20420 

MULT  YT=VY1AY 

f.M 

. 3 

20500 

SUM  SS=:'T  + YT 

8V=  2 

20600 

SUB  EE=S-3i 

1200 

Y=0.3 

20650 

FUHC  E-FF'-EE 

1 700 

:-':-:=e , 939 

20700 

MULT  ;<i=E»x;: 

HOP 

YV=  953 

20710 

MULT  Y1=E1YY 

1500 

T;i=e  05 

20720 

MULT  X2=X116X 

I 600 

TV=0  05 

20730 

MULT  Y2=Y11hY 

1700 

hX-i}  1 

20740 

MULT  y.3-X2»T 

1300 

Hr=0  1 

20750 

MULT  V3=Y24T 

1305 

n-;=i60 

22000 

INTO  XOIJGXX. 

1010 

FOR  iv.=  l TO  H7. 

23000 

INTG  Y<V0t&Yl. 

1S20 

X=C)>! 

24000 

IHTG  XX<XS*#-12 

1030 

Y=0V 

25000 

INTG  YY<Y5»I-12 

1340 

/;x=  9999 

26000 

INTG  UXiXUG’. 

1650 

YV=  9995 

27000 

INTG  UX<X3»G2 

1900 

(l>:-0  0 

23000 

INTG  UYCYltG'/. 

2100 

UV^iO  0 

29000 

INTG  UY(Y3»G2 

2200 

UY=0  0 

30000 

OISPT  3 

2250 

0 

30100 

OISPT  S3 

C.3  Second  Order  Differential  Equation/Multiple  Runs:  by  R.  Martinez.  NOSC  Code  6353 


T HORIZ  UERSUS 

* 

X.XO  UERT 

1 

STOP  0T  LINE  808 

1 

> 

1 

1 

50  CLEftP  STOCK 

100  TM=0  9999 

I. 

200  OT=TM/1O0 

I* 

300  G--.=  10 

*1 

750  - 10 

P-  9 

370  fop’ 12=1  TO  3 

■ 

400  ;;=o  s 

500  XD=0  0 

* . . 

550  T=0 

6PO  DRUM 

710  R=P-0.3 

728  NEXT  12 

*•’•.** 

•900  END 

1 . • 

908  14  Ml.  441411.41:1; 

, . 

20100  fUl.T  P=XDIR 

20200  SUM  C!=X+P 

20400  INTG  X0-;01G12 

**,  •*  / •*, 

20500  INTG  X'XD1G2 

i *./•...••**  / • 

21*600  DISPT  X 

” •***.  .•'*  •*  **•••’ 

20700  DISPT  XD 

L 

to 
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